home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-fopg-ositransition-00.txt < prev    next >
Text File  |  1993-03-03  |  46KB  |  1,581 lines
  1. INTERNET OSI INTEGRATION, COEXISTENCE AND INTEROPERABILITY ISSUES
  2.  
  3.                  **********DRAFT**********
  4.  
  5.                         Version 0.1
  6.  
  7.                          R. Callon
  8.                          R. Hagens
  9.                          R. Nitzan
  10.  
  11.                        July 23, 1990
  12.  
  13.  
  14.  
  15.  
  16. 1.  Status
  17.  
  18. This working document is a DRAFT intended for review.   Com-
  19. ments are encouraged.
  20.  
  21.  
  22. 2.  Introduction
  23.  
  24. The intent of this document is to provide technical descrip-
  25. tions  of the issues involved in the integration of the Open
  26. Systems Interconnect (OSI) protocols  into  the  operational
  27. networks which interconnect and comprise the "Internet". The
  28. issues raised and solutions discussed are a  result  of  the
  29. Federal  Networking Council (FNC) OSI Planning Group (FOPG).
  30. The members of the FOPG represent several Federal Government
  31. agencies  such  as  the  Department  of  Energy  (DOE),  the
  32. National Science Foundation (NSF) the  National  Aeronautics
  33. and  Space  Administration (NASA), the National Institute of
  34. Standards and Technology (NIST) under the Department of Com-
  35. merce, as well as University experts.
  36.  
  37. The Internet is composed of many networks.  Some are  funded
  38. privately  and  some  are funded by the U.S. Government, yet
  39. all currently  use  the  Transport  Communications  Protocol
  40. (TCP)/Internet  Protocol  (IP) [2,3] and can communicate via
  41. some physical connection point.   Other  networks  use  dif-
  42. ferent  protocols  that  physically  connect,  yet  they are
  43. essentially disjoint because the protocols they use  do  not
  44. interoperate  transparently with TCP/IP.  As both non-TCP/IP
  45. networks and the Internet begin to use OSI, the interconnec-
  46. tivity  expands  and hence the size of the Internet.  There-
  47. fore, OSI integration  into  the  non-TCP/IP  networks  that
  48. interconnect,  specifically  the  large DECnet* networks, is
  49. considered as well.
  50.  
  51. *DECnet is a trade mark of Digital Equipment Corporation
  52.  
  53. It is recognized that there is a commitment to integrate OSI
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.                     DRAFT FOPG-OSI Spec        July 23, 1990
  65.  
  66.  
  67. into  many  networks  that compose the Internet, however, it
  68. must also be recognized that there  is  typically  a  higher
  69. commitment  to  continue providing existing network services
  70. to users.  There are key pieces missing from the OSI infras-
  71. tructure  such  as inter-domain routing, directory/name ser-
  72. vice and network management.  The missing components coupled
  73. with the installed user base of TCP/IP will prevent OSI from
  74. supplanting the TCP/IP protocol  suite.   As  a  result,  in
  75. addition  to  the  integration  of  OSI, there will be coex-
  76. istence and interoperability amongst OSI, TCP/IP and  poten-
  77. tially DECnet for the indefinite future.
  78.  
  79. Despite the current difficulties, there  is  large  momentum
  80. behind  the  OSI development, and it is anticipated to be in
  81. wide use eventually.  Some of the most  optimistic  specula-
  82. tion  has  been  that OSI will be in predominate use 5 years
  83. from now, while the more pessimistic speculation is that  it
  84. will take another 10 years.
  85.  
  86. The integration and transition of any new protocols  into  a
  87. large  established  network base will require adjustments or
  88. fine tuning to the protocols themselves as well  as  to  how
  89. they  are used.  This is a normal expectation for changes of
  90. this magnitude.  Throughout this paper an attempt is made to
  91. identify  the  issues and potential problems that will arise
  92. as the new OSI protocols are integrated.  This is considered
  93. an important part of the initial planning stage.
  94.  
  95. 2.1.  Scope and Objectives
  96.  
  97. Each administration responsible for their networks may  have
  98. their  own policy and guidelines for the integration of OSI.
  99. Due to the diversity of existing administrations,  networks,
  100. and  users, it is nearly impossible to generate a common OSI
  101. integration plan.  Administrations serving user  communities
  102. with  different requirements may require different solutions
  103. that are specific to their particular needs.
  104.  
  105. Therefore, this document does not contain "The OSI  Integra-
  106. tion  Plan".   Rather,  it  attempts  to address the various
  107. issues and scenarios that may  arise  in  the  general  case
  108. i.e.,  coexistence  and  interoperability between TCP/IP and
  109. OSI.
  110.  
  111. The objectives of this paper are to provide:
  112.  
  113.  
  114. +    A  compendium  of  coexistence   and   interoperability
  115.      issues.
  116.  
  117.  
  118. +    A summary of solutions to the various  coexistence  and
  119.      interoperability  issues.  This includes an analysis of
  120.  
  121.  
  122.                                                       Page 2
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.                     DRAFT FOPG-OSI Spec        July 23, 1990
  131.  
  132.  
  133.      each solution as well as an indication of  issues  that
  134.      require work and are currently lacking resources.
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.                                                       Page 3
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.                     DRAFT FOPG-OSI Spec        July 23, 1990
  197.  
  198.  
  199. 3.  THE CURRENT AND FUTURE INTERNET
  200.  
  201. It is important to  understand  the  state  of  the  current
  202. TCP/IP  Internet while analyzing the subsequent issues.  The
  203. current model of the evolving Internet is based around three
  204. components:  high  speed backbones, large regional networks,
  205. and local site networks. The local area networks connect  to
  206. regional networks. In turn, the regional networks connect to
  207. the high speed backbones.  There are variations, e.g.,  some
  208. local sites have direct high speed backbone connections, and
  209. many regionals interconnect to each other through  "backdoor
  210. routes".   In  fact, the number of connections is increasing
  211. resulting in a meshed environment, even  though  there  have
  212. been successful attempts to consolidate links.
  213.  
  214. The backbones are government  funded  networks,  where  some
  215. have multi-protocol requirements.  For example, both DOE and
  216. NASA backbones have multi-protocol mission support  require-
  217. ments  for  TCP/IP  and  DECnet.   Most of the backbones are
  218. planning to start carrying operational ISO 8473  []  traffic
  219. in either 1990 or early 1991.
  220.  
  221. Regional networks, though originally funded by  the  govern-
  222. ment,  are  tending to become privately operated.  Regionals
  223. will likely provide operational ISO 8473 forwarding capabil-
  224. ities as user requirements become apparent.
  225.  
  226. Most OSI software (including a full OSI stack)  can  operate
  227. on  a  local  area network. However, a lack of user require-
  228. ments for operational OSI software has slowed the deployment
  229. of OSI on local area networks.
  230.  
  231.  
  232. 4.  Looking Towards OSI
  233.  
  234. Rapid transition from TCP/IP to OSI is not likely to  occur.
  235. Rather,  it is anticipated that an extended period will take
  236. place  during  which  both  protocol  suites  will   be   in
  237. widespread  use.   This  will  require  both coexistence and
  238. interoperability between the two protocol suites.
  239.  
  240.  
  241. 4.1.  Coexistence
  242.  
  243. Coexistence among protocol suites occurs when separate  pro-
  244. tocols  run  simultaneously on the same network. Coexistence
  245. options vary from running dual protocol stacks to  operating
  246. physically separate networks.
  247.  
  248. Physically separate networks are usually not practical since
  249. they   require   separate  circuits,  devices,  routers  and
  250. resources in general. This is (typically)  incongruous  with
  251. the strong cost incentive to share physical resources.
  252.  
  253.  
  254.                                                       Page 4
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.                     DRAFT FOPG-OSI Spec        July 23, 1990
  263.  
  264.  
  265. Dual protocol stacks can run in parallel in  an  end  system
  266. and/or an intermediate system. Dual protocol (or multiproto-
  267. col in general) schemes are usually cost  effective  because
  268. they  allow  two  or  more software stacks to share the same
  269. physical resources. However, this may lead to an increase in
  270. the  number  of resources required by the machine and in the
  271. complexity of the operational management of two  essentially
  272. separate networks.
  273.  
  274.  
  275. 4.2.  Interoperability
  276.  
  277. Interoperability becomes an issue when the two end points of
  278. a  communication path do not use the same protocol suite. In
  279. this situation, a conversion mechanism is required to bridge
  280. the gap between the two protocols.
  281.  
  282. Interoperability issues arise at many layers.  For  example,
  283. two  machines  may have the same application protocol suite,
  284. but have incompatible network layer protocols. On the  other
  285. hand, two machines may share a compatible network layer pro-
  286. tocol, but have incompatible applications.
  287.  
  288. Interoperability may require that the user be aware  of  the
  289. presence  of  two protocol suites.  In the long run, this is
  290. unacceptable on a large scale.
  291.  
  292.  
  293. 4.3.  Mixed Protocol Environment
  294.  
  295. In a mixed environment, more  than  one  protocol  stack  is
  296. used.  The  stack  itself  may  be mixed, e.g., TCP/IP lower
  297. layers and OSI upper layers.  It may also be an  environment
  298. where  a pure protocol stack is trying to communicate with a
  299. mixed or different protocol stack, e.g., an OSI  end  system
  300. trying  to  communicate  with another end system running OSI
  301. applications with TCP/IP lower layers.
  302.  
  303.  
  304. 5.  Status of Issues by Protocol Layer
  305.  
  306. The following sections, categorized by protocol layer,  dis-
  307. cuss OSI and TCP/IP coexistence and interoperability.
  308.  
  309.  
  310. 5.1.  Physical Layer
  311.  
  312. There are no known physical layer issues  that  need  to  be
  313. resolved.
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.                                                       Page 5
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.                     DRAFT FOPG-OSI Spec        July 23, 1990
  329.  
  330.  
  331. 5.2.  Data Link Layer
  332.  
  333. The Government OSI Profile (GOSIP) Version 2.0  [20]  speci-
  334. fies  3  data  link layer protocols: 1) High Level Data Link
  335. Communication (HDLC) Link Access Procedure  B  (LAP  B),  in
  336. conjunction  with  X.25 (ISO 7776) and Pt-Pt subnetworks; 2)
  337. ISO 8802/2 (LLC 1)  in  conjunction  with  ISO  8802/3,  ISO
  338. 8802/4,  or  ISO  8802/5;  and 3) Q.921 for operation on the
  339. ISDN D channel and ISO 7776 (LAP B) for operation on ISDN  B
  340. channels.
  341.  
  342. The Internet standard data link layer is the Point to  Point
  343. Protocol (PPP) [22].
  344.  
  345.  
  346. 5.2.1.  Coexistence Issue: OSI and IP over HDLC
  347.  
  348. Status: resolved.
  349.  
  350. OSI and IP packets may be distinguished on an HDLC  link  by
  351. examining the Network Layer Protocol ID (NLPID) field of the
  352. HDLC or X.25 header.  NLIPDs have been assigned for  IP  and
  353. ISO  8473.   This  allows both protocols to run over HDLC or
  354. over HDLC/X.25.
  355.  
  356.  
  357. 5.2.2.  Coexistence Issue: OSI and IP over 802.x
  358.  
  359. Status: resolved.
  360.  
  361. OSI and IP packets may be distinguished on  802.2  links  by
  362. examining  the Destination Service Access Point (DSAP) field
  363. in the 802.2 header. DSAP values have been assigned for  OSI
  364. packets as well as IP packets.
  365.  
  366.  
  367. 5.2.3.  Coexistence Issue: OSI and IP over PPP
  368.  
  369. Status: work and resources needed.
  370.  
  371. PPP indicates what type  of  protocol  follows  in  a  field
  372. within  the  PPP header.  Currently a value is defined indi-
  373. cating IP as the next layer protocol.  There is some minimal
  374. work  needed to specify a next level protocol value indicat-
  375. ing ISO 8473.
  376.  
  377. 5.3.  Network Layer
  378.  
  379. Several pieces of the OSI network layer such as the specifi-
  380. cation  of CLNP, and the ES-IS routing protocol are complete
  381. and provide the transmission of OSI network layer data  over
  382. local  area  networks.  However, for the network layer to be
  383. used on a  wide  scale,  IS-IS  routing  protocols  must  be
  384.  
  385.  
  386.                                                       Page 6
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                     DRAFT FOPG-OSI Spec        July 23, 1990
  395.  
  396.  
  397. deployed.
  398.  
  399.  
  400. 5.3.1.  Operational Issue: OSI Intra-domain IS-IS protocol
  401.  
  402. Status: in progress.
  403.  
  404. The IS-IS intra-domain  dynamic  routing  protocol  [25]  is
  405. currently  a Draft Proposal in the ISO/IEC standards organi-
  406. zations.  IS-IS for ISO 8473 is  being  progressed  rapidly,
  407. and  is  anticipated  to become an International Standard in
  408. 1991.
  409.  
  410.  
  411. 5.3.2.  Coexistence Issue:  Integrated  or  Parallel  Intra-
  412. domain protocols
  413.  
  414. Status: work and resources needed.
  415.  
  416. Widespread deployment of both IP and CLNP require the opera-
  417. tion  of  a  routing  protocol. Two basic approaches to this
  418. problem have been identified. In the  integrated  approach,a
  419. single routing protocol is deployed which supports the rout-
  420. ing of both IP and CLNP packets. In the  Parallel  approach,
  421. two distinct, independent protocols are operated.
  422.  
  423. A detailed analysis of these  two  approaches  is  required.
  424. This  analysis must address the advantages and disadvantages
  425. of each approach and  recommend  the  conditions  when  each
  426. approach is favorable.
  427.  
  428.  
  429. 5.3.3.  Operational Issue: Intra-domain IS-IS for Dual Use
  430.  
  431. Status: in progress.
  432.  
  433. The IETF IS-IS working group is working on integrated  rout-
  434. ing  for  both  IP and ISO 8473.  There is an Internet Draft
  435. RFC which is expected to become an RFC in mid 1990.
  436.  
  437.  
  438. 5.3.4.  Operational Issue: Inter-domain Routing
  439.  
  440. Status: in progress, resources needed.
  441.  
  442. There is a draft specification of  an  Inter-Domain  Routing
  443. Protocol  (IDRP)  for consideration as the U.S. contribution
  444. to the ISO/IEC standards committees.  The  previous  efforts
  445. by  ECMA  and the development of the Boarder Router Protocol
  446. (BRP) contributed to form the basis for this IDRP.
  447.  
  448. There is also an Internet effort  for  inter-domain  routing
  449. based on source routing.  It has the added feature of policy
  450.  
  451.  
  452.                                                       Page 7
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.                     DRAFT FOPG-OSI Spec        July 23, 1990
  461.  
  462.  
  463. based routing.  It is not clear how these  two  efforts  can
  464. relate to each other.
  465.  
  466. Static, manually updated tables will be used  in  the  short
  467. term for inter-domain routing in an ISO 8473 Internet.  This
  468. will be required until  there  is  either  an  International
  469. Standard  for  an  IDRP  or  until an interim IDRP is agreed
  470. upon, implemented and commercially available.
  471.  
  472. Static tables are unacceptable on a large scale  because  of
  473. the  requirement  for human intervention to re-route traffic
  474. in the event of link failure, and because of the extra  bur-
  475. den caused in maintaining large routing tables manually.
  476.  
  477. It is expected that the lack of an IDRP will greatly  reduce
  478. the  deployment  of  the  OSI Connectionless Network Service
  479. (CLNS).  Thus, there is an urgent requirement for an interim
  480. IDRP agreement and implementation.
  481.  
  482.  
  483. 5.3.5.  Operational Issue: NSAP Format
  484.  
  485. Status: in progress.
  486.  
  487. Structure for the Domain Specific Part (DSP) of the  Network
  488. Service  Access  Point  (NSAP)  address  has been defined in
  489. GOSIP Version 2.0.
  490.  
  491. The GOSIP format is solidified  pending  GOSIP  Version  2.0
  492. final  release.  (GOSIP Version 1.0 [] will have errata that
  493. specifies the GOSIP Version 2.0 NASAP address format.)   The
  494. lower  portion  of  the DSP has structure that is compatible
  495. with the IS-IS intra-domain routing  protocol  requirements.
  496. The  GOSIP  Version  2.0  format  should  be  used for those
  497. administrations which are getting their address  assignments
  498. from the US government address space.
  499.  
  500. ANSI also assigns NSAPS with a format that has no  structure
  501. imposed  on  the  DSP.  These addresses will be used by non-
  502. government networks.  A common structure such as defined  in
  503. GOSIP Version 2.0 should be adopted and used.
  504.  
  505.  
  506. 5.3.6.  Operational Issue: NSAP Guidelines
  507.  
  508. Status: in progress.
  509.  
  510. The NSAP working group in the IETF is working on  guidelines
  511. regarding  OSI  addressing.  Results may be submitted to the
  512. OSI Implementors Workshop  and  become  part  of  the  GOSIP
  513. Users' Guide for GOSIP Version 2.0.
  514.  
  515. See Appendix ? for details of these guidelines.
  516.  
  517.  
  518.                                                       Page 8
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.                     DRAFT FOPG-OSI Spec        July 23, 1990
  527.  
  528.  
  529. 5.3.7.  Operational Issue: ISO 8473 Echo
  530.  
  531. Status: in progress.
  532.  
  533. The IETF has completed work on an  ISO  8473  echo  function
  534. [23].   It  must be supported in order to get it through the
  535. ISO/IEC standards committees.  This Protocol is considered a
  536. vital tool for simple network operational support.
  537.  
  538.  
  539. 5.3.8.  Coexistence Issue: CLNS/CONS Interoperability
  540.  
  541. Status: in progress, resources needed.
  542.  
  543. It is anticipated that there will be wide spread use of  the
  544. connection-less  and connection-oriented network services. A
  545. solution to this problem must be reached. An  ISO  technical
  546. report [21] specifies a possible solution.
  547.  
  548.  
  549. 5.4.  Transport Layer
  550.  
  551. Transport relays (or gateways or bridges) have been proposed
  552. as  both  a coexistence and an interoperation strategy. This
  553. is discussed in a later section.
  554.  
  555.  
  556. 5.5.  Session and Presentation
  557.  
  558. No work is needed.  The Session and Presentation Layers  for
  559. the OSI suite operate independently of the TCP/IP suite.
  560.  
  561.  
  562. 5.6.  Electronic Mail
  563.  
  564. There are several issues relating to the operation of  X.400
  565. (the  OSI  electronic  mail system) and coexistence of X.400
  566. and RFC 822 mail systems.
  567.  
  568.  
  569. 5.6.1.  Operational Issue: X.400 routing
  570.  
  571. Status: in progress.
  572.  
  573. There is some work in the NIST X.400 SIG on routing of X.400
  574. messages between MTAs. <TODO: get info from stef on this>
  575.  
  576.  
  577. 5.6.2.  Interoperation Issue: An X.400/RFC 822 gateway
  578.  
  579. Status: in progress.
  580.  
  581. The specification of an RFC 822/X.400 gateway is RFC 987/RFC
  582.  
  583.  
  584.                                                       Page 9
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.                     DRAFT FOPG-OSI Spec        July 23, 1990
  593.  
  594.  
  595. 1148
  596.  
  597.  
  598. 5.6.3.  Operational Issue: Structure of X.400 addresses
  599.  
  600. Status: in progress, resources needed.
  601.  
  602. In order to deploy X.400 in  the  Internet,  Internet  X.400
  603. users  must  be  given  X.400  addresses.  How  should these
  604. addresses be constructed? The two basic choices are to  con-
  605. struct  X.400  addresses based upon X.400 naming guidelines,
  606. or to construct X.400 addresses based upon existing RFC  822
  607. addresses.
  608.  
  609. In general, the recommended  practice  is  to  create  X.400
  610. addresses  that  are  meaningful  to  the  organization (and
  611. without regard to any preassigned RFC 822 addresses).
  612.  
  613.  
  614. 5.6.4.  Operational Issue: Use of the PRMD/ADMD field
  615.  
  616. Status: needs work, resources needed.
  617.  
  618. The US must make a policy decision on the use of blank  ADMD
  619. fields  and  the  registration  of  PRMD  names.  Lack  of a
  620. national policy regarding  these  attributes  will  lead  to
  621. chaos  as  government,  private,  and  public X.400 networks
  622. become interconnected.
  623.  
  624. An initiative with the US State Department (Study Groups  A-
  625. D)  has  been  formed  to oversee the creation of the proper
  626. committee to study this issue. (See Stef).
  627.  
  628.  
  629. 5.6.5.  Interoperation Issue: Identification of the users
  630.  
  631. Status: in progress, resources needed.
  632.  
  633. A small but growing population of users in the U.S. Internet
  634. are  starting  to  use  X.400.   These  X.400  users must be
  635. addressable by RFC822 mail users.  RFC987 and RFC1148  gate-
  636. ways  exist that allow translation and mapping between X.400
  637. and RFC822 messages.  One strategy that  European  countries
  638. have  taken is to define MX records that appear to be normal
  639. RFC822 addresses, but which actually point to an RFC987/1148
  640. gateway  to  translate  messages into the X.400 world.  This
  641. gives X.400 users an Internet-style address that is concise,
  642. easy   to  type,  and  consistent  with  tradition  Internet
  643. addresses.
  644.  
  645. Another strategy is to embed the X.400  address  within  the
  646. RFC 822 syntax.
  647.  
  648.  
  649.  
  650.                                                      Page 10
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.                     DRAFT FOPG-OSI Spec        July 23, 1990
  659.  
  660.  
  661. Looking toward the future, it would be delightful if a  user
  662. could  use  a  common,  natural address syntax for all mail,
  663. whether sent to an X.400 system, or to an  RFC  822  system.
  664. The X.500 directory is a key to this situation.
  665.  
  666. A strategy for the Internet  must  be  discussed  and  docu-
  667. mented.
  668.  
  669.  
  670. 5.6.6.  Operational Issue: 987/1148 mapping table support
  671.  
  672. Status: in progress, resources needed.
  673.  
  674. Complex operation of an 987/1148 gateway requires the global
  675. distribution  of  static  address  mapping  information. The
  676. current practice of manual distribution will not  scale.  An
  677. experimental use of the DNS to store the mapping information
  678. has been undertaken at the University of Wisconsin.  Storage
  679. of the mapping information in the DNS allows the information
  680. to be stored in a distributed manner.
  681.  
  682. The use of the DNS to support RFC 987/1148 mapping  informa-
  683. tion must be reviewed and documented.
  684.  
  685.  
  686. 5.6.7.  Operational Issue: 987/1148 gateway security
  687.  
  688. Status: work and resources needed.
  689.  
  690. There is considerable work in both the  Internet  (RFC  822)
  691. community  and  the  ISO  (X.400)  community on security for
  692. electronic mail. It does not appear that there has been  any
  693. serious study of how a mail gateway affects the two security
  694. models.
  695.  
  696.  
  697. 5.7.  Virtual Terminal Protocol
  698.  
  699. Status: This section needs to be reviewed by a VTP expert
  700.  
  701. The Virtual Terminal Protocol VTP  is  the  OSI  version  of
  702. remote login.  There has been a VTP profile written, that is
  703. similar to the Internet TELNET protocol.  There currently is
  704. an  implementation  of  this, where both the OSI VTP and the
  705. Internet TELNET can run in the same host. This results in an
  706. application  relay running directly in the host, thereby by-
  707. passing the added  complication  of  determining  where  the
  708. application  gateway  is  located.   A user can login to the
  709. host via either VTP or TELNET and from there  perform  addi-
  710. tional remote logins to other machines with either TELNET or
  711. VTP.
  712.  
  713. There is also another profile which is more in tune with the
  714.  
  715.  
  716.                                                      Page 11
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.                     DRAFT FOPG-OSI Spec        July 23, 1990
  725.  
  726.  
  727. International Telegraph and Telephone Consultative Committee
  728. (CCITT) recommendation for the terminal standard X.3,  X.28,
  729. and  X.29.  The functionality is very similar to TELNET.  In
  730. addition, there is a third generic VTP profile.
  731.  
  732. In regards to the user locating the application gateway, one
  733. solution  is  to  require a two step login.  The user expli-
  734. citly logs into the application gateway via  VTP  or  TELNET
  735. and from there uses TELNET or VTP to get to another destina-
  736. tion.
  737.  
  738.  
  739. 5.8.  File Transfer
  740.  
  741. Status: This section needs to be reviewed by a FTAM expert
  742.  
  743. There is <??> work being  done  on  an  application  gateway
  744. between  the OSI File Transfer, Access and Management (FTAM)
  745. [] and the Internet File Transfer Protocol (FTP) [].
  746.  
  747. As in the VTP and TELNET scenario, it is feasible for a user
  748. use  a  two  step approach. For file transfer it is a burden
  749. since multiple file transfers may be  executed  in  a  login
  750. session as well as in application software.
  751.  
  752.  
  753. 6.  Issues Spanning Multiple Layers
  754.  
  755. 6.1.  Directory Services
  756.  
  757.  
  758. 6.1.1.  Operational Issue: organization of the name space
  759.  
  760. Status: work and resources needed.
  761.  
  762. Currently there is work being done in the X.500  OSI  Imple-
  763. mentors  Workshop.  In addition, an IETF X.500 working group
  764. has been started.
  765.  
  766.  
  767. 6.1.2.  Coexistence Issue: Multi-Stack protocol selection
  768.  
  769. Status: work and resources needed.
  770.  
  771. A dual stack end system must select which protocol stack  to
  772. use  when  trying  to  get to a specific remote location via
  773. directory service query.  Thus, the  directory  system  must
  774. contain  information  to aid in protocol stack selection. In
  775. addition, the directory must provide some aid in the  inden-
  776. tification  a  gateway if the two end systems do not share a
  777. common protocol stack.
  778.  
  779. This topic is in the scope of the IETF X.500 working group.
  780.  
  781.  
  782.                                                      Page 12
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.                     DRAFT FOPG-OSI Spec        July 23, 1990
  791.  
  792.  
  793. 6.1.3.  Coexistence Issue:  Interoperability  between  X.500
  794. and the Internet DNS
  795.  
  796. Status: work and resources needed.
  797.  
  798. This topic is in the scope of the IETF X.500 working group.
  799.  
  800.  
  801. 6.2.  Security, Access Control and Authentication
  802.  
  803. Status: work and resources needed.
  804.  
  805. Multi-protocol secuity issues have not been  studied.   How-
  806. ever,  it  is likely that multi-stack interoperability prob-
  807. lems will result if the security  for  IP-only  environments
  808. and  security  for  OSI-only environments is not integrated.
  809. Coordination between the IP  and  OSI  security  efforts  is
  810. necessary  to  ensure  security  when trying to interoperate
  811. between the two electronic mail services.
  812.  
  813.  
  814. 6.3.  Network Management
  815.  
  816. Status: dazed and confused.
  817.  
  818. The IETF is defining how to use the Simple  Network  Manage-
  819. ment  Protocol  (SNMP)  to manage pure OSI systems.  This is
  820. likely to lead to confusion.
  821.  
  822. This section needs review by an expert  in  network  manage-
  823. ment.
  824.  
  825.  
  826. 6.4.  Summary of the Status
  827.  
  828. The following table summarizes the status  of  the  work  at
  829. various levels.
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.                                                      Page 13
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.                     DRAFT FOPG-OSI Spec        July 23, 1990
  857.  
  858.  
  859.  
  860.     Layer/Issue                                Current     Responsible
  861.                                                Status       Group/Person
  862.  
  863.     Datalink
  864.     + OSI & IP over Ethernet/802.2,3,4         DONE
  865.     + OSI & IP over HDLC/LAPB                  DONE
  866.     + OSI & IP over X.25                       DONE
  867.     + OSI & IP over PPP                        WORK NEEDED IETF WG
  868.     Routing
  869.     + IS-IS for OSI only                       IN PROGRESS ANSI/ISO
  870.     + IS-IS for OSI and IP (dual)              EXPERIMENTALIS-IS WG
  871.     + Inter-Domain Routing                     IN PROGRESS ANSI
  872.     + Coexistence analysis                     WORK NEEDED IETF
  873.     Network
  874.     + NSAP address format                      DONE
  875.     + NSAP guidelines                          IN PROGRESS NSAP WG/NIST
  876.     + ISO 8473 Echo                            IN PROGRESS ANSI/ISO
  877.     + CLNS/CONS Interoperating                 IN PROGRESS ANSI/ISO
  878.     Electronic mail
  879.     + X.400 Routing                            IN PROGRESS NIST X.400 SIG
  880.     + RFC 822/X.400 Gateway                    EXPERIMENTALIETF
  881.     + O/R Address Format                       WORK NEEDED
  882.     + PRMD/ADMD Field                          WORK NEEDED
  883.     + User Identification                      IN PROGRESS IETF
  884.     + 987/1148 support                         IN PROGRESS IETF
  885.     + Gateway Security                         WORK NEEDED
  886.     Virtual Terminal
  887.     File Transfer
  888.     Directory Services
  889.     + Name space                               IN PROGRESS NIST/IETF
  890.     + Multi-stack query                        WORK NEEDED IETF X.500 WG
  891.     + X.500/DNS interoperation                 WORK NEEDED IETF X.500 WG
  892.     Security and Access Control
  893.     + Dual environments                        WORK NEEDED
  894.     Network Management
  895.     + CMIP/SNMP                                WORK NEEDED
  896.     Mixed Stack
  897.     + ISODE                                                ?
  898.  
  899.  
  900.  
  901. 7.  Strategies and Scenarios
  902.  
  903. In the follow sections, various  coexistence  scenarios  are
  904. examined.   Each  scenario  is defined by type of the source
  905. and destination protocol stack. In order to keep the  combi-
  906. nations  under  control,  the  following  types  of protocol
  907. stacks are defined:
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.                                                      Page 14
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.                     DRAFT FOPG-OSI Spec        July 23, 1990
  923.  
  924.  
  925.  
  926.     Network Layer                              Application Suite
  927.     
  928.  
  929.     TCP/IP                                     OSI
  930.     TCP/IP                                     Internet
  931.     CLNS-OSI                                   OSI
  932.     CONS-OSI                                   OSI
  933.  
  934.  
  935. The combination of TCP/IP Network Layers  and  OSI  applica-
  936. tions  is  accomplished  according  to  RFC  1006 [24]. This
  937. mechanism operates the TP0 protocol,  along  with  a  simple
  938. packetization  protocol  on top of the TCP/IP, which is used
  939. as a connection-oriented network service.  With the RFC 1006
  940. approach,  OSI  applications can establish a connection over
  941. any TCP/IP network.
  942.  
  943. The first  stack  definition  (TCP/IP  Network  Layers,  OSI
  944. Applications)  includes  both  an RFC 1006 mixed stack and a
  945. pure stack OSI system connected to an OSI LAN (where the LAN
  946. is surrounded by TCP/IP-only capable routers).
  947.  
  948. Of the possible 16 possible combinations of source and  des-
  949. tination pairs, some are non-issues since they do not result
  950. in a mixed stack environment, such as a TCP/IP host communi-
  951. cating  with  another  TCP/IP  host over an IP network.  The
  952. important cases are:
  953.  
  954.  
  955.     Case Source                         Destination
  956.          Stack                          Stack
  957.     
  958.  
  959.     1    [TCP/IP Net,   Internet Appl]  [TCP/IP Net,   OSI Appl]
  960.     2    [TCP/IP Net,   Internet Appl]  [CLNS-OSI Net, OSI Appl]
  961.     3    [TCP/IP Net,   OSI Appl]       [CLNS-OSI Net, OSI Appl]
  962.     4    [TCP/IP Net,   OSI Appl]       [CONS-OSI Net, OSI Appl]
  963.     5    [CLNS-OSI Net, OSI Appl]       [CONS-OSI Net, OSI Appl]
  964.  
  965.  
  966.  
  967. These are only the simplest of cases. More complicated tran-
  968. sit cases may arise where different networks are in the mid-
  969. dle. These cases are discussed in a later section.
  970.  
  971.  
  972. 7.1.  Case 1
  973.  
  974. This case requires an application layer gateway.
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.                                                      Page 15
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.                     DRAFT FOPG-OSI Spec        July 23, 1990
  991.  
  992.  
  993. 7.2.  Case 2
  994.  
  995. Case two requires an application gateway with the added bur-
  996. den of an interoperability problem at the network layer. The
  997. most likely solution to this problem requires an application
  998. gateway  with  two network layer protocols (IP Net and CLNS-
  999. OSI Net).
  1000.  
  1001. ADVANTAGES:
  1002.  
  1003. o No modification to the end system software
  1004.  
  1005. DISADVANTAGES:
  1006.  
  1007. o Performance degradation, especially apparent  in  interac-
  1008. tive mode.
  1009.  
  1010. o Locating the application gateway is an issue for  the  end
  1011. system.
  1012.  
  1013. o Functionality loss if one application has greater capabil-
  1014. ities and hence do not map to the other application.
  1015.  
  1016.  
  1017. 7.3.  Case 3
  1018.  
  1019. Case three can be solved with a transport relay (or  network
  1020. layer encapsulation if the [TCP/IP Net, OSI App] really is a
  1021. pure OSI system isolated in a TCP/IP internet).
  1022.  
  1023.  
  1024. 7.3.1.  A Transport Relay
  1025.  
  1026. Transport relaying can be used when two end systems are run-
  1027. ning  common  applications and the lower layer protocols (up
  1028. to and including the transport layer)  are  different.   The
  1029. transport  relay  converts  one lower layer stack to another
  1030. stack, mapping relevant information between the   protocols.
  1031. All  traffic  must explicitly go through a transport service
  1032. relay at the boundary where the underlying network  services
  1033. differ.   There  are  several  cases  that need this type of
  1034. capability. For example, an end system running TCP/IP  lower
  1035. layers and OSI applications communicating with an end system
  1036. running OSI lower layers (CONS or  CLNS)  and  OSI  applica-
  1037. tions.
  1038.  
  1039. ADVANTAGES:
  1040.  
  1041. o Interoperability between OSI upper layers  over  a  TCP/IP
  1042. lower layer network.
  1043.  
  1044. o Complete transparency to the OSI upper layers
  1045.  
  1046.  
  1047.  
  1048.                                                      Page 16
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1057.  
  1058.  
  1059. DISADVANTAGES:
  1060.  
  1061. o The end system must modify its transport service.
  1062.  
  1063. o Locating the relay is an issue that requires static tables
  1064. or a new protocol.
  1065.  
  1066. o End-to-end packet encryption incurs a security compromise.
  1067. This is because the encryption algorithm must be re-computed
  1068. in the relay which requires knowledge of the encryption key.
  1069. A  relay  having knowledge of an encryption key is the secu-
  1070. rity risk.
  1071.  
  1072. o End-to-end guarantee of non-corrupted data is compromised.
  1073. A  packet  having  a data error while in the transport relay
  1074. will get through without notice since the checksum is recom-
  1075. puted using a different checksum algorithm.
  1076.  
  1077.  
  1078. 7.3.2.  Network Layer Encapsulation
  1079.  
  1080. An ISO 8473 packet may be  encapsulated  in  an  IP  packet.
  1081. Specifically, the ISO 8473 protocol runs above the IP layer.
  1082. Once encapsulated, the ISO 8473 portion is treated  as  data
  1083. by  the  IP layer and is indistinguishable from any other IP
  1084. packet.  The encapsulated ISO 8473 packet may  be  forwarded
  1085. through  any IP router.  When the IP portion is removed (de-
  1086. encapsulated),  leaving  the  ISO  8473  packet  intact,  it
  1087. appears  to  the  OSI network layer as if it has traversed a
  1088. single subnetwork.
  1089.  
  1090. This scheme  is  useful  when  an  isolated  CLNS  LAN  must
  1091. traverse  a  TCP/IP based internetwork on its way to an CLNS
  1092. based destination. This scheme is most efficient  when  only
  1093. one   system   (an   IS)   on   the   LAN   is   allowed  to
  1094. encapsulate/decapsulate.
  1095.  
  1096. ADVANTAGES:
  1097.  
  1098. o Interoperability between OSI upper layers  over  a  TCP/IP
  1099. lower layer network.
  1100.  
  1101. o Complete transparency to the OSI upper layers
  1102.  
  1103. o No modification to the end system software, unless the end
  1104. system is the encapsulator.
  1105.  
  1106.  
  1107. DISADVANTAGES:
  1108.  
  1109. o   Deriving   encapsulators'   and   de-encapsulators'   IP
  1110. addresses  from  NSAP  addresses requires static tables or a
  1111. new protocol.
  1112.  
  1113.  
  1114.                                                      Page 17
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1123.  
  1124.  
  1125. 7.4.  Case 4
  1126.  
  1127. Case four can be solved with a transport relay.
  1128.  
  1129.  
  1130. 7.5.  Case 5
  1131.  
  1132. Case five can be solved with a transport relay.
  1133.  
  1134.  
  1135. 7.6.  More complicated transit situations
  1136.  
  1137. In all of the solutions that facilitate interoperability and
  1138. coexistence,  there is a question as to what the result will
  1139. be when the situation becomes complex.   For  example,  con-
  1140. sider  two  end systems where the path between them transits
  1141. several networks, some OSI (both X.25 and ISO 8473) and some
  1142. TCP/IP.   At  what  point  does the solution break? How many
  1143. cases is it reasonable to analyze?
  1144.  
  1145. Here are several:
  1146.  
  1147. Case 6: [OSI Net, OSI Appl] <-> [TCP/IP TRANSIT] <-> [OSI Net, OSI Appl]
  1148.  
  1149. Case 7: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [OSI Net, OSI Appl]
  1150.  
  1151. Case 8: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [TCP/IP Net, OSI Appl
  1152. ]
  1153.  
  1154.  
  1155. Case 9: [TCP/IP Net, OSI Appl] <-> [OSI TRANSIT] <-> [TCP/IP TRANSIT] <-->
  1156.                                              [OSI Net, OSI Appl]
  1157.  
  1158.  
  1159.  
  1160. Case 6 is best handled  by  network  encapsulation.  Case  7
  1161. requires an application gateway at the edge of the OSI TRAN-
  1162. SIT network. Case 8 requires both an application gateway and
  1163. network  encapsulation  (IP  within CLNP). In case 9, if the
  1164. [TCP/IP Net, OSI Appl] is really an isolated pure OSI stack,
  1165. then  encapsulation across the TCP/IP TRANSIT is all that is
  1166. required. If the [TCP/IP Net, OSI Appl] is an RFC 1006 host,
  1167. then  both  IP  encapsulation and a transport service bridge
  1168. may be required.
  1169.  
  1170. These situations can generally be broken down by the follow-
  1171. ing  guidelines.  If the application changes, then an appli-
  1172. cation gateway is required. When an application  gateway  is
  1173. required and the network service is incompatible, it is best
  1174. to locate the application gateway at  the  point  where  the
  1175. network service changes.
  1176.  
  1177. If an application gateway is not required then  the  network
  1178. service is the primary consideration. If the network service
  1179.  
  1180.  
  1181.                                                      Page 18
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1190.  
  1191.  
  1192. is the same at both ends of the connection, then it is  best
  1193. to  use  network layer encapsulation. Otherwise, if the net-
  1194. work service is different at both ends, a transport relay is
  1195. required.
  1196.  
  1197.  
  1198. 8.  CURRENT STATUS OF OSI IN THE INTERNET
  1199.  
  1200.  
  1201. 8.1.  NATIONAL BACKBONES
  1202.  
  1203. Most of the national backbone networks plan to start provid-
  1204. ing  limited  Connectionless  Network Service (CLNS) in late
  1205. 1990 or early  1991.   Some  of  the  agency  backbones  are
  1206. upgrading  DECnet Phase IV to DECnet Phase V, which includes
  1207. ISO 8473 end to end service.
  1208.  
  1209. There are two issues to resolve before most of the backbones
  1210. can  provide  operational ISO 8473: (1) routing domain boun-
  1211. dary designation and (2) address registration and dissemina-
  1212. tion.   Until  IS-IS  dynamic  intra-domain routing, network
  1213. management and directory service is available  commercially,
  1214. limited  operational  capabilities  can be expected for some
  1215. networks.
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.                                                      Page 19
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1256.  
  1257.  
  1258. 9.  APPENDIX A
  1259.  
  1260. 9.1.  DEFINITION OF ACRONYMS
  1261.  
  1262. ADMD     Administrative Management Domain
  1263. AFI      Authority and Format Identifier
  1264. BRP      Boarder Router Protocol
  1265. CCITT    International Telegraph and Telephone Consultative Committee
  1266. CLNP     Connectionless Network-layer Protocol
  1267. CLNS     Connectionless Network Service
  1268. CMIP     Common Management Information Protocol
  1269. CONS     Connection-Oriented Network Service
  1270. DCC      Data Country Code
  1271. DECnet   Digital Equipment Corporation Network
  1272. DNS      Distributed Name Service
  1273. DSP      Domain Specific Part
  1274. DOE      Department of Energy
  1275. ECMA     European ??
  1276. ES       End System
  1277. FNC      Federal Networking Council
  1278. FOPG     Federal Networking Council OSI Planning Group
  1279. FTAM     File Transfer, Access and Management
  1280. FTP      File Transfer Protocol
  1281. GOSIP    Government Open System Interconnect Profile
  1282. HDLC     High level Data Link Control
  1283. IDRP     Inter Domain Routing Protocol
  1284. IEC      International Electrotechnical Committee
  1285. IETF     Internet Engineering Task Force
  1286. IP       Internet Protocol
  1287. ISO      International Organization for Standards
  1288. NASA     National Aeronautics and Space Administration
  1289. NIST     National Institute of Standards and Technology
  1290. NSAP     Network Service Access Point
  1291. OSI      Open Systems Interconnection
  1292. OSPF     Open Shortest Path First
  1293. PPP      Point-to-Point Protocol
  1294. RFC      Request For Comment
  1295. SNMP     Simple Network Management Protocol
  1296. TCP      Transport Communications Protocol
  1297. VTP      Virtual Terminal Protocol
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.                                                      Page 20
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1322.  
  1323.  
  1324. 10.  REFERENCES
  1325.  
  1326. [1] "U.S. Government Open Systems Interconnections Profile".
  1327. August  1988.  U.S. Federal Information Processing Standards
  1328. Publication 146.  Version 1.
  1329.  
  1330. [2] J.B Postel, "Internet Protocol",   Request  For  Comment
  1331. #791,  September  1981.  DDN Network Information Center, SRI
  1332. International.
  1333.  
  1334. [3] J.B Postel, "Transmission Control Protocol", Request For
  1335. Comment #793, September 1981.
  1336.  
  1337. [4] ISO 7498  "Basic Reference Model for Open Systems Inter-
  1338. connection"
  1339.  
  1340. [5] ISO/IEC  8473, Information Processing Systems, "Protocol
  1341. for  Providing  the  Connectionless-mode Network Service and
  1342. Provision of Underlying Service".  May, 1987.
  1343.  
  1344. [6] M.T. Rose, D.E. Case, "ISO Transport on Top of the TCP",
  1345. Request  For  Comment #1006, 1987 June. DDN Network Informa-
  1346. tion Center, SRI International.
  1347.  
  1348. [7] ISO/IEC 8571-1 Information Processing  Systems  -  "File
  1349. Transfer,  Access  and  Management Part 1: General Introduc-
  1350. tion". April, 1988.
  1351.  
  1352. [8] J.B. Postel, J.K. Reynolds,  "File  Transfer  Protocol",
  1353. Request For Comment #959, 1985 October. DDN Network Informa-
  1354. tion Center, SRI International.
  1355.  
  1356. [9] CCITT Recommendation X.400 (Red  Book,  1984),  "Message
  1357. Handling Systems: Systems Model-Service Elements".
  1358.  
  1359. [10] J.B. Postel, "Simple Mail Transfer Protocol",   Request
  1360. For  Comment  #821,  August  1982.  DDN  Network Information
  1361. Center, SRI International.
  1362.  
  1363. [11] Information Processing Systems, "Virtual Terminal  Ser-
  1364. vice:  Basic Class", August, 1987. Draft International Stan-
  1365. dard 9040.
  1366.  
  1367. [12] J.B. Postel, J.K. Reynolds, "Telnet Protocol Specifica-
  1368. tion", May 1983.  DDN Network Information Center, SRI Inter-
  1369. national.
  1370.  
  1371. [13] Marshall T. Rose. "The Open Book - A Practical Perspec-
  1372. tive  on OSI".  Prentice Hall, Englewoods Cliffs, 1990. ISBN
  1373. 0-13-643016-3.
  1374.  
  1375. [14] Tim Boland. "Government  Open  Systems  Interconnection
  1376. Profile   Users'   Guide".   August,   1989.   NIST  Special
  1377.  
  1378.  
  1379.                                                      Page 21
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1388.  
  1389.  
  1390. Publication 500-163.
  1391.  
  1392. [15] "Digital Network Architecture  (Phase  V)".  September,
  1393. 1987.  Digital Equipment Corporation. Maynard, Massachusetts
  1394.  
  1395. [16] ISO/IEC JTC  1/SC6/N4945:1989,  Telecommunications  and
  1396. Information  "Exchange  Between  Systems, Intra-Domain IS-IS
  1397. Routeing Protocol"
  1398.  
  1399. [17] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin,  "Sim-
  1400. ple Network Management Protocol", Request For Comment #1098,
  1401. April 1989. DDN Network  Information  Center,  SRI  Interna-
  1402. tional.
  1403.  
  1404. [18] J. Moy, "Open Shortest Path First", Request For Comment
  1405. #1131,  1989  October.  DDN  Network Information Center, SRI
  1406. International.
  1407.  
  1408. [19] "Stable  Implementation  Agreements  for  Open  Systems
  1409. Interconnection  Protocols", Version 2 Edition 4. September,
  1410. 1989. NIST Special Publication 500-162.
  1411.  
  1412. [20] "U.S. Government  Open  Systems  Interconnections  Pro-
  1413. file". July 1988.  U.S. Federal Information Processing Stan-
  1414. dards Publication 146.  Draft Version 2.
  1415.  
  1416. [21] ISO/DTR 10172: Information Processing  Systems  -  Data
  1417. Communications  -  Network/Transport  Protocol  Interworking
  1418. Specification.
  1419.  
  1420. [22] "Point to Point Protocol",  Request   For  Comment  #?,
  1421. 1989. DDN Network Information Center, SRI International
  1422.  
  1423. [23] RFC 1139
  1424.  
  1425. [24] RFC 1006
  1426.  
  1427. [25] ISO/DP 10589: Information  Processing  Systems  -  Data
  1428. Communications  - Intermediate system to Intermediate system
  1429. Intra-Domain routing exchange protocol for use  in  Conjunc-
  1430. tion with the Protocol for providing the COnnectionless-mode
  1431. Network Service (ISO 8473).
  1432.  
  1433. [] NLPID
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.                                                      Page 22
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1454.  
  1455.  
  1456.                      TABLE OF CONTENTS
  1457.  
  1458. Section 1 Status ......................................    1
  1459. Section 2 Introduction ................................    1
  1460. Section 2.1 Scope and Objectives ......................    2
  1461. Section 3 THE CURRENT AND FUTURE INTERNET .............    4
  1462. Section 4 Looking Towards OSI .........................    4
  1463. Section 4.1 Coexistence ...............................    4
  1464. Section 4.2 Interoperability ..........................    5
  1465. Section 4.3 Mixed Protocol Environment ................    5
  1466. Section 5 Status of Issues by Protocol Layer ..........    5
  1467. Section 5.1 Physical Layer ............................    5
  1468. Section 5.2 Data Link Layer ...........................    6
  1469. Section 5.2.1 Coexistence Issue:  OSI  and  IP  over
  1470.      HDLC .............................................    6
  1471. Section 5.2.2 Coexistence Issue:  OSI  and  IP  over
  1472.      802.x ............................................    6
  1473. Section 5.2.3 Coexistence Issue: OSI and IP over PPP
  1474.      ..................................................    6
  1475. Section 5.3 Network Layer .............................    6
  1476. Section 5.3.1 Operational  Issue:  OSI  Intra-domain
  1477.      IS-IS protocol ...................................    7
  1478. Section  5.3.2  Coexistence  Issue:  Integrated   or
  1479.      Parallel Intra-domain protocols ..................    7
  1480. Section 5.3.3 Operational Issue: Intra-domain  IS-IS
  1481.      for Dual Use .....................................    7
  1482. Section  5.3.4   Operational   Issue:   Inter-domain
  1483.      Routing ..........................................    7
  1484. Section 5.3.5 Operational Issue: NSAP Format ..........    8
  1485. Section 5.3.6 Operational Issue: NSAP Guidelines ......    8
  1486. Section 5.3.7 Operational Issue: ISO 8473 Echo ........    9
  1487. Section   5.3.8   Coexistence    Issue:    CLNS/CONS
  1488.      Interoperability .................................    9
  1489. Section 5.4 Transport Layer ...........................    9
  1490. Section 5.5 Session and Presentation ..................    9
  1491. Section 5.6 Electronic Mail ...........................    9
  1492. Section 5.6.1 Operational Issue: X.400 routing ........    9
  1493. Section 5.6.2 Interoperation Issue: An X.400/RFC 822
  1494.      gateway ..........................................    9
  1495. Section 5.6.3 Operational Issue: Structure of  X.400
  1496.      addresses ........................................   10
  1497. Section  5.6.4  Operational  Issue:   Use   of   the
  1498.      PRMD/ADMD field ..................................   10
  1499. Section 5.6.5 Interoperation  Issue:  Identification
  1500.      of the users .....................................   10
  1501. Section 5.6.6 Operational  Issue:  987/1148  mapping
  1502.      table support ....................................   11
  1503. Section 5.6.7 Operational  Issue:  987/1148  gateway
  1504.      security .........................................   11
  1505. Section 5.7 Virtual Terminal Protocol .................   11
  1506. Section 5.8 File Transfer .............................   12
  1507. Section 6 Issues Spanning Multiple Layers .............   12
  1508. Section 6.1 Directory Services ........................   12
  1509.  
  1510.  
  1511.                                                      Page 23
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.                     DRAFT FOPG-OSI Spec        July 23, 1990
  1520.  
  1521.  
  1522. Section 6.1.1 Operational Issue: organization of the
  1523.      name space .......................................   12
  1524. Section   6.1.2   Coexistence   Issue:   Multi-Stack
  1525.      protocol selection ...............................   12
  1526. Section 6.1.3  Coexistence  Issue:  Interoperability
  1527.      between X.500 and the Internet DNS ...............   13
  1528. Section   6.2   Security,   Access    Control    and
  1529.      Authentication ...................................   13
  1530. Section 6.3 Network Management ........................   13
  1531. Section 6.4 Summary of the Status .....................   13
  1532. Section 7 Strategies and Scenarios ....................   14
  1533. Section 7.1 Case 1 ....................................   15
  1534. Section 7.2 Case 2 ....................................   16
  1535. Section 7.3 Case 3 ....................................   16
  1536. Section 7.3.1 A Transport Relay .......................   16
  1537. Section 7.3.2 Network Layer Encapsulation .............   17
  1538. Section 7.4 Case 4 ....................................   18
  1539. Section 7.5 Case 5 ....................................   18
  1540. Section 7.6 More complicated transit situations .......   18
  1541. Section 8 CURRENT STATUS OF OSI IN THE INTERNET .......   19
  1542. Section 8.1 NATIONAL BACKBONES ........................   19
  1543. Section 9 APPENDIX A ..................................   20
  1544. Section 9.1 DEFINITION OF ACRONYMS ....................   20
  1545. Section 10 REFERENCES .................................   21
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.                                                      Page 24
  1578.  
  1579.  
  1580.  
  1581.